1. Field of the Invention
The present invention relates to the field of communications. More particularly, the present invention relates to an apparatus, process and program for detecting a status of one or more communications paths in a networked computer system.
2. Discussion of Background Information
Traditionally, in Internet Mobility Protocol (IMP) bound to Internet Protocol (IP) address zero and port zero (e.g., INADDR_ANY), the stack would forward the frames from an interface of its choosing and receive frames on all interfaces. Address selection was essentially accomplished by trying each address in turn until a response was received. Generally, the source address of the received frame was considered to be the correct address to communicate with the server. Static routes could be used to force selection of one interface over another in certain situations. The only opportunity to control which interface the IMP traffic flowed on was to use policy to make interface speed adjustments, to hide adapters from IMP, or to add static routes to force the stack to send IMP traffic from a specific interface. Such policy is described in U.S. Pat. Nos. 7,136,645 and 7,293,107, the disclosures of which are expressly incorporated by reference herein in their entireties.
Given specific configurations, IMP could survive downstream outages on otherwise active interfaces by going unreachable and selecting an alternate address, thereby forcing the use of an alternate interface. An advanced setting would then allow testing of the higher speed interface in case the downstream problem clears up. The drawback to this approach is the requirement that a host's topology must support a separate address routable over a specific interface to enable any of these benefits.
Internet Mobility Protocol (IMP) was limited to address selection to control the selected gateway. Given two interfaces and a static route that forces the selection of one slower interface over the other, IMP selects the address on the faster network. When the network on the faster interface remains connected to the stack but it no longer has communication to a working gateway, the gateway can be considered to have failed. Once unreachable during retransmission IMP will begin to try alternate server addresses to see if a different address will reach the server. When it detects a response from the server, it uses the source address of the server which matches one of the addresses in the address list and communication resumes. The presence of the static route through the slower interface causes IMP to bypass the interface attached to the failed gateway. Now, the problem becomes how to ever come back to the higher speed interface, which, according to the known art, can be accomplished by a periodic IMP pings to the server through the other (failed) server address. This ping is done on a configurable time interval. When the ping is responded to, IMP switches to this address and communications resumes over the faster interface.
This was a very easy way to accomplish some limited failover detection and recovery mostly built on existing IMP functionality. The main problem with this approach is that it requires the user to have one server address assigned to one particular network interface. This works in some cases where the high speed network is private and the lower speed network is public (or vice-versus). However, the requirement for this topology and static route makes the solution difficult or impossible to solve in some cases. It is noted that RFC 816 (Fault Isolation and Recovery) and RFC 1122 (Requirements for Internet Hosts-Communication Layers) describe the standards for determining a failed gateway, and the disclosures of these documents are expressly incorporated by reference herein in their entireties.
Mobility can be configured to allow the client to use a slower interface to reach the server when there is a downstream network problem on the faster interface, even if the faster interface is still reporting a valid IP address. This is especially useful for interfaces that are connected to the device via Ethernet. Because the Ethernet connection to the wireless radio is constantly available whether the radio has a connection or not, the client can be fooled into thinking it has a good network connection and not release its IP address.
The client can have at least two interfaces, in which each interface can be connected to a different server address, e.g., of a mobility management server. By way of example, one interface can be connected to the server's NAT/external address via a public carrier, and another interface can be connected to its actual internal IP address over a local LAN. Alternatively, two or more NATs could be used for the two interfaces through various public or private backhaul systems. When the server becomes unreachable over the faster interface the client tries to reach the server over all of its known addresses. A static routes or strong routing ensures that connection attempts to the server's external address will be routed over the wireless wide area network (WWAN), not the faster (now failed) interface. Thus, the client is able to switch interfaces when a downstream network problem occurs.